-
Notifications
You must be signed in to change notification settings - Fork 122
Feature/admob 2021 stability in future usage #762
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/admob 2021 stability in future usage #762
Conversation
@@ -795,6 +795,8 @@ TEST_F(FirebaseAdMobTest, TestBannerView) { | |||
// Set the listener. | |||
TestBoundingBoxListener bounding_box_listener; | |||
banner->SetBoundingBoxListener(&bounding_box_listener); | |||
PauseForVisualInspectionAndCallbacks(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait to ensure that any callback attempts have time to complete before we start testing the listener.
@@ -390,21 +386,29 @@ Future<void> BannerViewInternalAndroid::Resume() { | |||
|
|||
Future<void> BannerViewInternalAndroid::Destroy() { | |||
firebase::MutexLock lock(mutex_); | |||
return InvokeNullary(kBannerViewFnDestroy, banner_view_helper::kDestroy); | |||
FutureCallbackData<void>* callback_data = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No longer use futures to track the destruction as the ReferenceCountedFutureImpl may be destroyed before the operation attempts to complete the future. This had caused a crash on some Android runs which was responsible for a lot of flake.
TBH, the Application should have already invoked Destroy()
prior to this object's destruction. Invoking it again here isn't required. I guess this code was put here to protect our users from accidentally leaking memory.
In theory this code could be removed, but I'll keep it anyway. But moving forward there doesn't seem to be a good reason to block the destructor and wait, though. Instead I'll start an asynchronous attempt to destroy the Java resources, if they haven't been destroyed already, and then return immediately from here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think there's no reason to actually wait for the Java destruction to complete.
@@ -227,7 +227,9 @@ const char* GetRequestAgentString() { | |||
// Mark a future as complete. | |||
void CompleteFuture(int error, const char* error_msg, | |||
SafeFutureHandle<void> handle, FutureData* future_data) { | |||
future_data->future_impl.Complete(handle, error, error_msg); | |||
if (future_data->future_impl.ValidFuture(handle)) { | |||
future_data->future_impl.Complete(handle, error, error_msg); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just an extra safety check.
@@ -32,29 +32,20 @@ | |||
|
|||
InterstitialAdInternalIOS::~InterstitialAdInternalIOS() { | |||
firebase::MutexLock lock(mutex_); | |||
// Clean up any resources created in InterstitialAdInternalIOS. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code was waiting to run on the main thread but all it was doing was setting values to null. While all AdMob operations should be conducted on the main thread, we're not actually performing any AdMob operations here, so let's simplify this code and just assign the null values here.
@@ -33,22 +33,13 @@ | |||
RewardedAdInternalIOS::~RewardedAdInternalIOS() { | |||
firebase::MutexLock lock(mutex_); | |||
// Clean up any resources created in RewardedAdInternalIOS. | |||
Mutex mutex(Mutex::kModeNonRecursive); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Simplify in the same way that we did for Interstitials, above.
} | ||
synchronized (mBannerViewLock) { | ||
if (destructor_invocation == false) { | ||
notifyBoundingBoxChanged(mBannerViewInternalPtr); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't invoke the bounding box listener if this destroy() invocation originated from the C++ object destructor. The bounding box listener won't be there anymore.
@@ -390,21 +386,29 @@ Future<void> BannerViewInternalAndroid::Resume() { | |||
|
|||
Future<void> BannerViewInternalAndroid::Destroy() { | |||
firebase::MutexLock lock(mutex_); | |||
return InvokeNullary(kBannerViewFnDestroy, banner_view_helper::kDestroy); | |||
FutureCallbackData<void>* callback_data = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think there's no reason to actually wait for the Java destruction to complete.
❌ Integration test FAILEDRequested by @DellaBitta on commit b495952
Add flaky tests to go/fpl-cpp-flake-tracker |
Description
Fixes stability issues regarding race conditions in the AdMob SDK:
Testing
FTL testing. Local Testing. Integration CI
Type of Change
Place an
x
the applicable box: